Modification of a sensor data management system to enable sensors as a service

ABSTRACT

A modification of a sensor data management system to enable discrete sensor applications. A sensor data control system enables discrete sensor applications to control the configuration, collection, processing, and distribution of sensor data produced by selected sensors at various monitored locations. The sensor service offered by the sensor data control system can be leveraged by any sensor application having an interest in any part of one or more monitored locations.

This application is a continuation-in-part of non-provisionalapplication Ser. No. 14/710,170, filed May 12, 2015, non-provisionalapplication Ser. No. 14/710,191, filed May 12, 2015, non-provisionalapplication Ser. No. 14/710,209, filed May 12, 2015, non-provisionalapplication Ser. No. 14/710,247, filed May 12, 2015, non-provisionalapplication Ser. No. 14/710,652, filed May 13, 2015, non-provisionalapplication Ser. No. 14/710,711, filed May 13, 2015, and non-provisionalapplication Ser. No. 14/710,766, filed May 13, 2015. Each of thenon-provisional applications claim the benefit of and priority toprovisional application No. 61/992,307, filed May 13, 2014, and toprovisional application No. 62/136,959, filed Mar. 23, 2015. Each of theabove-identified applications is incorporated herein by reference in itsentirety.

BACKGROUND

Field

The present disclosure relates generally to sensor applications,including a modification of a sensor data management system to enablesensors as a service.

Introduction

Sensors can be used to monitor physical environment conditions. Wirelesssensor networks can be used to collect data from distributed sensors andto route the collected sensor data to a central location.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features can be obtained, a more particular descriptionwill be rendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments and are not therefore to be consideredlimiting of its scope, the disclosure describes and explains withadditional specificity and detail through the use of the accompanyingdrawings in which:

FIG. 1 illustrates an example of a sensor data management system.

FIG. 2 illustrates an example framework that enables discrete sensorapplication development in a sensors as a service model.

FIG. 3 illustrates example sensor applications that leverage a sensorservice accessible via a network.

FIG. 4 illustrates a first example of a sensor application process.

FIG. 5 illustrates an example embodiment of a wireless node.

FIG. 6 illustrates an example embodiment of a sensor module unit.

FIG. 7 illustrates an example embodiment of a housing of a wireless nodethat exposes connector interfaces.

FIG. 8 illustrates an example embodiment of a housing of a sensor moduleunit.

FIG. 9 illustrates an example embodiment of a node attached to aplurality of sensor module units.

FIG. 10 illustrates a second example operation of a sensor applicationprocess.

FIG. 11 illustrates a third example operation of a sensor applicationprocess.

DETAILED DESCRIPTION

Various embodiments are discussed in detail below. While specificimplementations are discussed, it should be understood that this is donefor illustration purposes only. A person skilled in the relevant artwill recognize that other components and configurations may be usedwithout parting from the spirit and scope of the present disclosure.

Sensors provide a mechanism for discovering and analyzing a physicalenvironment at a monitored location. In general, a monitored locationcan represent any area where one or more sensors are deployed. Themonitored location may or may not represent a physical area havingclearly defined boundaries. As would be appreciated, the extent of themonitoring application itself provides a sense of boundary to themonitored location. In one example, the monitored location can representa building such as a home, hotel, school, community building, stadium,convention center, warehouse, office building, multi-dwelling unit, orother defined building structure. In another example, the monitoredlocation can represent an area of control such as a vehicle or containerin any mode of transport, an asset collection area, a construction zone,or any monitored area that can be fixed or movable. In yet anotherexample, the monitored location can represent an area proximate to anarticle, device, person or other item of interest upon which one or moresensors are attached.

FIG. 1 illustrates an example of the collection and analysis of datafrom sensors installed at a monitored location. As illustrated, sensordata management system 100 collects sensor data from a plurality ofsensors installed at monitored location 110. This collection portion ofsensor data management system 100 provides sensor data to control andanalysis portion 120. Control and analysis portion 120 includes database122 for storage of the collected sensor data. Dashboard 123 can beembodied as an online platform that allows a customer to view the sensordata from monitored location 110. Dashboard 123 can therefore representa management tool authored by sensor data management system 100 thathelps promote customer understanding of the sensor data.

In one example, sensor data management system 100 can represent anend-to-end solution provided by a single vendor that enters into aservice contract with a customer. Under the terms of the contract, thevendor can install the sensor hardware at monitored location 110,collect, process and store sensor data in database 122, and provide thecustomer with visibility to the sensor data via dashboard 123. In thisexample framework, the vendor would operate and otherwise control allaspects of sensor data management system 100 in providing asingle-vendor solution to the customer. This single-vendor solution maynot enable a full implementation of sensors as a service.

Notably, the customer would have a relationship with the single vendorthat installed the sensor hardware at monitored location 110. Thissingle vendor would control access to the sensor data in database 122.The vendor's dashboard 123 would therefore represent the only means bywhich a customer can view the sensor data. A consequence of thisrestriction is that the customer is reliant on the vendor's dashboardfor every aspect of analytics and other functionality needed by thecustomer. Dashboard 123 would necessarily be positioned as anall-encompassing solution. Rarely are such solutions optimized for therange of solutions required for the particular needs of a variety ofcustomers. For example, the vendor's dashboard may have industry-leadingfunctionality in a first area, while having average functionality in asecond area. Since the customer has a relationship with the singlevendor for a single solution, the customer would have difficultyleveraging industry-leading functionality offered by a second vendor inthe second area. Moreover, the customer would not be able to change tothe second vendor because the first vendor effectively owns the sensorhardware installed at the monitored location. A suboptimal solution forthe customer therefore results.

In the present disclosure it is recognized that single-vendor solutionscan potentially impede the creation of sensors as a service. Thedeployment of individual sensors at a monitored location is part of thegrowing trend of the Internet of Things (IoT). The connectivity of theindividual sensors through a wireless sensor network enables inclusionof those sensors as part of an open network. A single-vendor solutionunfortunately restricts access to the sensors as well as to the datacollected by them. In contrast, the sensors as a service model seeks topromote the open usage of the sensors and the data collected by them toany party having an interest in at least part of the monitored location.

FIG. 2 illustrates an example framework that enables discrete sensorapplication development in a sensors as a service model. Central to thissensors as a service model is sensor data control system 220. Ingeneral, one or more servers in sensor data control system 220 can beconfigured to facilitate the various processes that enable a collectionof sensor data from the plurality of monitored locations 210-n,processing and storage of sensor data in a database, and a distributionof sensor data to a plurality of sensor applications 230-n. Theplurality of monitored locations 210-n and the plurality of sensorapplications 230-n can interface with sensor data control system 220 viaweb application programming interface (API) 240. In one embodiment, webAPI 240 would be based on HTTP methods such as GET, PUT, POST, andDELETE.

As illustrated, sensor data control system 220 can collect sensor datafrom the plurality of monitored locations 210-n via web API 240. Forexample, sensor data control system 220 can receive the latest sensorreadings using HTTP POST methods from the plurality of monitoredlocations 210-n. Via web API 240, sensor data control system 220 cancollect a first set of sensor data from a first plurality of sensorsinstalled at a first monitored location, collect a second set of sensordata from a second plurality of sensors installed at a second monitoredlocation, . . . and collect an N^(th) set of sensor data from an N^(th)plurality of sensors installed at an N^(th) monitored location. The Ncollected sets of sensor data can be stored in a database as sensor data221. In one embodiment, aggregation data 222 can also be generated bysensor data control system 220 based on sensor data 221. In general,aggregation data 222 can represent any processed form of sensor data221.

In one application, a sensor data value can be transformed via a definedconversion relationship into a single aggregation data value. Forexample, a number of detected pulses can be transformed using a definedconversion relationship into a measure of consumption (e.g., power). Inanother application, a plurality of sensor data values can be processedthrough a defined conversion relationship into a single aggregation datavalue. For example, a plurality of sensor data values can be analyzed todetermine whether an alert should be triggered. In another example, aplurality of sensor data values such as voltage and current can beprocessed to produce a measure of power. In yet another scenario, aplurality of sensor data values can be grouped together into anaggregation of data values. For example, a plurality of sensor datavalues can be grouped together to produce a customer report.

Sensor data 221 and/or aggregation data 222 are accessible by aplurality of sensor applications 230-n via web API 240. Morespecifically, sensor data control system 220 can provide a first set ofsensor data 221 and/or aggregation data 222 upon request by a firstsensor application, provide a second set of sensor data 221 and/oraggregation data 222 upon request by a second sensor application, . . .and provide an N^(th) set of sensor data 221 and/or aggregation data 222upon request by an N^(th) sensor application. Each of the distributedsets of sensor data 221 and/or aggregation data 222 can support therespective needs of the requesting sensor application 230-n. Therespective needs can relate to all or part of one or more monitoredlocations 210-n. The scope of a sensor application 230-n in meeting aparticular customer need would dictate the amount of sensor data 221and/or aggregation data 222 that is provided.

In one scenario, the set of sensor data 221 and/or aggregation data 222can relate to a specific set of sensors in a part of a monitoredlocation 210-n occupied by a building tenant. In another scenario, theset of sensor data 221 and/or aggregation data 222 can relate to aparticular type of sensors (e.g., power) in one or more monitoredlocations 210-n. In yet another scenario, the set of sensor data 221and/or aggregation data 222 can relate to a subset of sensors in aparticular monitored location over a specified time period (e.g., day,week, month, or other defined period of time) to perform an audit ofconditions of the physical environment at that monitored location. Here,it should also be noted, that the set of sensor data 221 and/oraggregation data 222 provided to a first sensor application can overlapin part with the set of sensor data 221 and/or aggregation data 222provided to a second sensor application.

As would be appreciated, a distributed set of sensor data 221 and/oraggregation data 222 can be customized to the needs of a particularsensor application 230-n. In that way, the systematic collection,processing and storage of sensor data by sensor data control system 220can be viewed as a sensor service from the perspective of sensorapplications 230-n. Significantly, any sensor application 230-n canrequest data associated with any sensor at any monitored location 210-nover any time period via web API 240. New sensor applications cancontinually be developed for analysis of sensor data 221 and/oraggregation data 222, thereby increasingly leveraging sensor data 221and aggregation data 222. Sensor data control system 220 can thereforebe positioned as a sensor data service platform upon which front-endsensor applications 230-n can be built.

In implementing a full-featured sensor service, sensor data controlsystem 220 can also enable sensor applications 230-n to customize thecollection and processing of sensor data. This customization increasesthe adaptability and flexibility of the sensor service in meeting theneeds of the sensor applications 230-n. In one embodiment, sensorapplications 230-n can customize the operation of sensor data controlsystem 220 using web API 240. These customizations can be stored in adatabase as settings 223.

In one example, a sensor application 230-n can specify a conversionfunction via web API 240 for application to one or more values of sensordata. The conversion function can be stored in the database as settings223 and applied to one or more values of sensor data 221 to produce oneor more values of aggregation data 222. In this manner, a sensorapplication 230-n can specify one or more conversion functions that areconfigured to prepare a set of inputs for use by the sensor application230-n. One advantage of the specification of such conversion functionsis that the sensor application 230-n is assured of receiving data of aknown type, of a known quantity, of a known accuracy, of a known format,or of any other expected characteristic for processing by the sensorapplication 230-n. In one scenario, this can be used to ensure thatsensor application 230-n can be easily re-purposed from another sensorapplication environment to the particular sensor service supported bysensor data control system 220. In general, the conversion functions canbe used to create standardized outputs from data generated by differenttypes of sensors. Another advantage of the specification of suchconversion functions is that the sensor application 230-n can bedesigned to operate at a specified level of complexity relative tosensor data control system 220. In one scenario, sensor application230-n can offload analysis functions to sensor data control system 220,thereby enabling the sensor application to perform simple functions(e.g., alerts) on received aggregation data 222. This scenario would beuseful in allowing sensor application 230-n to be implemented as alight-weight sensor application 230-n for download and installation on amobile computing device. This would be in contrast to a full-featuredsensor application 230-n that is intended for installation on a serverdevice and which is designed for heavy-duty processing and analysisfunctions. As would be appreciated, conversion functions can be used tofacilitate a customized interaction between a sensor application 230-nand sensor data control system 220.

In another example, a sensor application 230-n can specify destinationsfor the distribution of sensor data 221 and/or aggregation data 222. Forexample, a sensor application 230-n can specify that separate subsets ofsensor data 221 and/or aggregation data 222 are distributed to differentdestinations. In this framework, the separate subsets of sensor data 221and/or aggregation data 222 may or may not correspond to distinctphysical parts of a monitored location. More generally, each subset ofsensor data 221 and/or aggregation data 222 can relate to a separateinterest by a sensor application to sensor data 221 and/or aggregationdata 222 produced by one or more monitored locations. In one embodiment,sensor data 221 and/or aggregation data 222 can be distributed todefined destinations using JavaScript Object Notation (JSON) formattedpackets.

In another example, a sensor application 230-n can specify, via web API240, configuration settings for application to a sensor network at amonitored location 210-n. The control provided by the specification ofthese configuration settings via web API 240 enables a sensorapplication 230-n to remotely configure a sensor network at a monitoredlocation 210-n. In various scenarios, the remote configuration commandswould customize the operation of a sensor network at a monitoredlocation 210-n to meet the needs of a given sensor application 230-n.

In one example, the customization of the operation of a monitoredlocation 210-n can include an activation or deactivation of a sensor atthe monitored location 210-n. This activation or deactivation cancorrespond to particular hours, days, weeks, months, or other periods oftime. In one scenario, the activation or deactivation commands cancorrespond to relevant periods of interest in the sensor data, whereinthe relevant periods of interest correspond to activity relating totenant occupancy, auditing, monitoring and verification, sales support,or other activities that have non-contiguous periods of interest and/orcontrol.

In another example, the customization of the operation of a monitoredlocation 210-n can include a change in the operation of a sensor at themonitored location 210-n. In various scenarios, the change in operationof the sensor can relate to a sensitivity characteristic, an accuracycharacteristic, a power characteristic, an energy saving characteristic,an operating mode characteristic, a data type or format characteristic,or any other characteristic that relates to an operation of the sensoror the data produced by the sensor. In one embodiment, the sensor issupported by a sensor module unit having an interface to the sensor(e.g., Modbus serial communication protocol). In this embodiment, thechange in operation can relate to a device address, a function code, aregister address, or any other parameter that facilitates a collectionof sensor data via the interface. As would be appreciated, the specificinterface supported by the sensor module unit would be implementationdependent.

In another example, the customization of the operation of a monitoredlocation 210-n can include a change in the operation of a node in asensor network at the monitored location 210-n. In various scenarios,the customization can relate to a frequency of sensor data collection, apower characteristic, an energy saving characteristic, an operating modecharacteristic (e.g., reset command), a data type or formatcharacteristic, or any other characteristic that relates to an operationof the node.

After customization commands have been forwarded to a monitored location210-n, the monitored location 210-n can return system update informationvia web API 240. This system update information can be recorded in thedatabase as system status 224. A sensor application 230-n can thenretrieve system status information from sensor data control system 220via web API 240 to confirm that the requested configuration changes havebeen correctly implemented by the sensor network at the monitoredlocation 210-n.

The configuration afforded via web API 240 enables a sensor application230-n to customize the operation of a sensor network from a locationremote from the monitored location 210-n. Notably, the sensorapplication 230-n can customize the operation of only part of the sensornetwork at a monitored location 210-n. For example, a first sensorapplication can be configured to provide an energy management companywith a view of sensor data relating to power consumption at a building,while a second sensor application can be configured to provide a tenantin the building with a view of sensor data relating to ambientconditions (e.g., temperature and humidity) in a part of the building.As these examples illustrate, a plurality of sensor applications 230-ncan be configured to leverage different subsets of sensors at one ormore monitored locations 210-n. From that perspective, sensor datacontrol system 220 provides a sensor service to a plurality of sensorapplications 230-n having varied interests into the detected physicalenvironment at the various monitored location 210-n.

FIG. 3 illustrates example sensor applications that can leverage asensor service accessible via a network. As illustrated, sensor service320 can be accessible by a plurality of sensor applications via web API340. In one example, sensor service 320 can be embodied as a sensor datacontrol system such as that described with reference to FIG. 2. Asnoted, a sensor data control system can be configured to control thecollection, processing, storage, and distribution of sensor datareceived from a plurality of monitored locations. The database of sensordata and aggregation data for the plurality of monitored locations canbe leveraged by any application having an interest in any part of adetected physical environment reflected by the sensor data and/oraggregation data. Once installed, the sensor networks at the pluralityof monitored locations become part of a sensor network infrastructurethat can serve the needs of any interested party, whether or not theinterested party was involved in the original deployment of the sensornetworks.

Sensor service 320 can be used by a variety of sensor applications thatcan be designed to meet customer needs at any level of granularity. Inthe present disclosure, it is recognized that sensor service 320 cansupport a marketplace or solution store of sensor applications. In thisframework, a sensor application provider can offer their sensorapplication to any customer having an interest in any part of a detectedphysical environment reflected by sensor data and/or aggregation dataoffered by sensor service 320.

To illustrate this marketplace framework, consider an example of atenant that signs a lease for office space in a building. The tenantcould use a first sensor application that provides energy managementfunctionality, use a second sensor application that provides tenantbilling features, and use a third sensor application that providesreports on ambient conditions in a climate-controlled storage area. Asthis example illustrates, the tenant can select a particular set ofsensor applications to provide the analytics and other information thetenant needs during occupancy of the leased space. Should a new tenantlease the same space, the new tenant can then select a different set ofsensor applications to meet their own particular needs during occupancyof the leased space.

As illustrated in FIG. 3, a marketplace for sensor applications can besegmented into a plurality of categories. A first example category caninclude Resource Management sensor applications that can each beconfigured to manage consumable resources such as electricity, water,gas, storage space, office space, conference rooms, or any othermeasured resource. A second example category can include Monitoring andVerification sensor applications that can each be configured to monitorand verify operation of a system (e.g., HVAC) in a monitored location.In one example, a monitoring and verification application can be used toperform audits of a system in a monitored location. A third examplecategory can include Tenant Billing sensor applications that can each beconfigured to generate bills for tenants for measured usage of someresource (e.g., electricity). A fourth example category can includeReports and Alerts sensor applications that can each be configured toperform compilation and analysis of sensor data and/or aggregation data.In one example, an alert sensor application can include complex analyticfunctions that can predict occurrence of future maintenance actions at amonitored location based on historical data produced by one or moresensors. A fifth example category can include Control sensorapplications that can each be configured to implement a control actionbased on an analysis of sensor data and/or aggregation data. In oneexample, a control sensor application can be configured to restrictusage of a consumable resource based on an analysis of current usagerelative to a budget. A sixth example category can include IndustrySpecific sensor applications that are targeted to a particular industrycontext. For example, a first set of sensor applications can bespecifically directed to the particular needs of schools, while a secondset of sensor applications can be specifically directed to theparticular needs of condo buildings. As these example categoriesillustrate, sensor service 320 can support the development of discretesensor applications that can be applied to any defined market segment.In general, the particular functionality needed by a customer can definea new category of sensor applications. Sensor service 320 supports thedevelopment of discrete sensor applications to meet any customer need.In comparison to a one-size-fits-all model, discrete sensor applicationsenable efficient and cost-effective solutions for customers.

To illustrate the operation of a sensor data control system in providinga sensor service, reference is now made to FIG. 4, which illustrates afirst example of a sensor application process. As illustrated, monitoredlocation 410 includes gateway 411, which communicates with sensor datacontrol system 420 via a network connection. The network connection canbe embodied in various forms depending upon the particularcharacteristics of monitored location 410. For example, where monitoredlocation 110 is a building in a developed area, then the networkconnection can be facilitated by a wired Internet connection via anInternet service provider (ISP). In another example, the networkconnection can be facilitated by a terrestrial or satellite basedwireless network to accommodate a remote physical area (or movable area)that may or may not include a building structure. Here, it should benoted that multiple gateways can be used at a monitored location,wherein each gateway supports a different set of nodes and has aseparate network connection to an operation center.

In one embodiment, gateway 411 communicates wirelessly with a pluralityof nodes 412-n that form a wireless mesh network. In one embodiment, thecommunication protocol between the plurality of nodes 412-n is based onthe IEEE 802.15.4 protocol. The wireless mesh network can be used tofacilitate bi-directional communication between sensor data controlsystem 420 and the plurality of nodes 412-n. Prior to describing thedetails of the sensor application process of FIG. 4, a description ofexample sensor network components is first provided.

FIG. 5 illustrates an example embodiment of a node. As illustrated, node500 includes controller 510 and wireless transceiver 520. Wirelesstransceiver 520 facilitates wireless communication between node 500 anda gateway or another node that operates as a relay between node 500 andthe gateway. In one embodiment, node 500 includes a wired transceiver(e.g., Ethernet) in addition to or as a replacement for wirelesstransceiver 520. The wired transceiver would enable node 500 tocommunicate with a gateway over a wired link.

Controller 510 collects sensor measurements from a set of sensor moduleunits via one or more universal sensor interfaces 530-n. Controller 510can also collect measurements from one or more sensors 540-n that arecontained within or otherwise supported by a housing of node 500. Invarious scenarios, the one or more sensors 540-n can facilitatemonitoring at that part of the monitored location, including the healthand/or status of node 500. Each universal sensor interface 530-n cansupport the connection of node 500 with a separate sensor module unit.The plug-and-play universal sensor interface facilitates the separationof the node communication infrastructure from the set of one or moresensor module units that are deployed at the location at which thesupporting node is installed.

Universal sensor interfaces 530-n can represent a combination ofhardware and software. The hardware portion of universal sensorinterfaces 530-n can include a wired interface that enablescommunication of different signals between node 500 and a connectedsensor module unit. In one example, the wired interface can be enabledthrough a connector interface, which is exposed by the housing of node500, and that is configured to receive a sensor module unit connectorvia removable, pluggable insertion.

In one embodiment, the wired interface can be based on a SerialPeripheral Interface (SPI) bus. In one example, the wired interfaceenables six connections: supply, ground, data in, data out, clock, anddevice select. The device select connection can be unique to each wiredinterface and can enable controller 510 in node 500 to select theparticular sensor module unit with which node 500 desires tocommunicate.

The software portion of the universal sensor interfaces 530-n caninclude a protocol that allows node 500 to communicate with a sensormodule unit. In one example protocol, controller 510 can be configuredto poll the various universal sensor interfaces 530-n to determinewhether any sensor module units are connected. As part of this protocol,controller 510 can first request a sensor ID from a sensor module unit.If the response read is “0”, then controller 510 would know that nosensor module unit is connected to that universal sensor interface530-n. If, on the other hand, the response read is not “0”, thencontroller 510 would ask for the number of data values that have to beretrieved and the number of bits on which the data values are coded. Inone example, the higher order 8-bits of a 16-bit communication betweencontroller 510 and a sensor module unit identifies the number of datavalues, while the lower order 8-bits of the 16-bit communicationidentifies the number of bits used to code each data value. Based on thenumber of data values to be retrieved, controller 510 would then collectthat number of data values, wherein each value can represent a differentsensor channel of the sensor module unit.

FIG. 6 illustrates an example embodiment of a sensor module unitdesigned for attachment to a node, an example of which was describedwith reference to FIG. 5. As illustrated, sensor module unit 600includes controller 610 that communicates over a universal sensorinterface with a supporting node. In one embodiment, sensor module unit600 supports the universal sensor interface with a connector 620configured for pluggable, removable insertion into a correspondingconnector interface exposed by the supporting node. In anotherembodiment, the sensor module unit can be coupled to the connectorinterface exposed by the supporting node via a connector attached to acable.

Sensor module unit 600 can support a plurality of sensors 630-n. Forexample, sensors supported by sensor module unit 600 can enable one ormore of the following: a temperature sensor application, a humiditysensor application, an air quality (e.g., CO₂) sensor application, alight sensor application, a sound sensor application, an occupationsensor application, a radiation sensor application, a contact sensorapplication, a pulse sensor application, a water sensor application, apower sensor application, a credential sensor application, or any othertype of sensor application configured to measure a characteristicassociated with a physical environment of a part of the monitoredlocation.

In one embodiment, a sensor can cooperate with an external sensorelement to produce sensor data. For example, sensor 630-2 can cooperatewith external sensor element 640 to gather energy monitoring data. Inone scenario, sensor 630-2 can be embodied as a pulse sensor that isconfigured to connect to an external energy monitoring meter product. Inanother scenario, sensor 630-2 can communicate with external sensorelement 640 via a Modbus interface, BACnet interface, or any otherinterface designed for communication with a monitoring product. As wouldbe appreciated, the particular method of cooperation between internaland external sensor elements supported by sensor module unit 600 wouldbe implementation dependent.

The plug-and-play nature of the connection of sensor module units tosupporting nodes facilitates a modular framework for installation at amonitored location. FIG. 7 illustrates an example embodiment of ahousing of a node such as the example illustration of node 500 in FIG.5. As illustrated, node 700 can have a housing configured to expose aplurality of connector interfaces 710. Each of the plurality ofconnector interfaces 710 can support the physical attachment of a singlesensor module unit. In the example illustration, each side of thehousing of node 700 exposes a single connector interface 710. In thepresent disclosure, it is recognized that the housing of the node can besubstantially larger than the housing of the sensor module unit. Thiscan result, for example, because the node can be designed withadditional components such as an internal power source (e.g., battery)that can involve additional volume requirements as compared to thesensor module units. It is therefore recognized that one embodiment of anode can have multiple sensor module units physically attached to asingle side of the node.

FIG. 8 illustrates an example embodiment of a housing of a sensor moduleunit such as the example illustration of sensor module unit 600 in FIG.6. As illustrated, sensor module unit 500 can have a housing configuredto support a connector 810. Connector 810 can be configured forpluggable, removable insertion into a corresponding connector interface710 exposed by the housing of node 700. The connection of sensor moduleunit 800 to node 700 via the insertion of connector 810 into connectorinterface 710 produces a true plug-and-play framework for the deploymentof sensors at a monitored location.

FIG. 9 illustrates an example data flow in a node such as the exampleillustration of node 500 in FIG. 5. As illustrated, node 900 interfaceswith a plurality of sensor module units, including sensor module unit920-1, sensor module unit 920-2, . . . , and sensor module unit 920-N.Connectors of sensor module unit 920-1, sensor module unit 920-2, . . ., and sensor module unit 920-N are each physically attached to separateconnector interfaces exposed by the housing of node 900. The attachmentof sensor module unit 920-1 to node 900 enables communication of databetween controller 921-1 and controller 910, the attachment of sensormodule unit 920-2 to node 900 enables communication of data betweencontroller 921-2 and controller 910, . . . , and the attachment ofsensor module unit 920-N to node 900 enables communication of databetween controller 921-N and controller 910. By these attachments, eachof sensor module units 920-1, 920-2, . . . , and 920-N can be coupled tonode 900 via a universal sensor interface having the connectivitycharacteristics described above.

As noted, the network formed by nodes at a monitored location creates acommunication infrastructure. This communication infrastructure enablesthe various sensors supported by a plurality of sensor module unitsdispersed around the monitored location to communicate with a gatewaydevice at the monitored location. The gateway device can interface witha sensor data control system via a public network.

Having described the details of the sensor network components at amonitored location, a detailed description of the example sensorapplication process of FIG. 4 is now provided. In this example, assumethat sensor application 430 requires (1) data from sensor readings fromsensors in sensor module unit S3 attached to node 412-1 to be takenevery 60 seconds, (2) a voltage measurement and current measurement tobe combined into a power measurement, and (3) the resulting powermeasurement data to be placed into a particular data format for inputinto an analytics module of sensor application 430. In variousscenarios, the data format can relate to singular data values and/or canrelate to multiple data values in the context of a report.

As illustrated, the process can begin with the communication by sensorapplication 430 of configuration settings to sensor data control system420. This part of the process is illustrated as process element “1” inFIG. 4. Sensor application 430 can submit configuration settings tosensor data control system 420 via web APIs. The submitted configurationsettings can be stored in a database as settings 421, and can be used asthe basis for adjusting the configuration of the sensor network atmonitored location 410 and to adjust the processing of sensor data 422received from monitored location 410. In this example, a firstconfiguration setting can be stored that would be the basis formodifying a data collection period of the sensors in sensor module unitS3 attached to node 412-1, a second configuration setting can be storedthat would be the basis for a conversion function for generation of apower measurement from a voltage measurement and current measurementtaken by the sensors in sensor module unit S3 attached to node 412-1,and a third configuration setting can be stored that would be the basisfor a conversion function to place the generated power measurement intothe data format desired by sensor application 430.

As noted, the web API supported by the sensor data control system can bebased on HTTP methods such as GET, PUT, POST, and DELETE. In submittingconfiguration settings to sensor data control system 420, sensorapplication 430 can use an HTTP PUT method to update a configurationsetting that controls a data collection period. For example, thefollowing HTTP PUT method can be used to define a data collection periodfor sensor module unit S3 attached to node 412-1 at monitored location410 as follows:

-   -   PUT https://api.senseware.co/Config/Node412_1/S3    -   {“pollingfreq”:“60”}        As this example illustrates, the HTTP PUT method can include a        host name “api.senseware.co”, an identifier for node 412-1, and        an identifier for sensor module unit S3. This information        enables sensor data control system 420 to identify the target of        the configuration setting related to the sensor data collection        period. In the body of the request, the “pollingfreq” is set to        60 seconds.

In one embodiment, the identifier for sensor module unit S3 can besufficiently unique in the context of monitored location 410 such thatthe identifier for node 412-1 is not needed in the HTTP PUT method. Inanother embodiment, a particular sensor module unit can be identified bya port identifier, which identifies the particular connector interfaceof node 412-1 to which a particular sensor module unit is attached. Forexample, where node 412-1 supports four sensor module units S1-S4, theneach of the four sensor module units can be uniquely identified by aport identifier having a value in the range of 1-4.

In one embodiment, the sensor data collection period can be applied toevery sensor supported by a sensor module unit. In another embodiment,the sensor data collection period can be applied to individual sensorssupported by a sensor module unit. For example, a first sensor supportedby a sensor module unit can have a first sensor data collection period,while a second sensor supported by the sensor module unit can have asecond sensor data collection period. To support sensor-specific datacollection periods, a further specification of particular sensorssupported by the sensor module unit can be included in the HTTP PUTmethod. For example, the HTTP PUT method can further include one or moreidentifiers for individual sensors.

Sensor application 430 can use the web API (e.g., HTTP POST method) tosubmit configuration settings for a first conversion function thatgenerates a power measurement from a voltage measurement and currentmeasurement, and a second conversion function that places the powermeasurement into the data format desired by sensor application 430. Forexample, the following HTTP POST method can be used to define the firstconversion function that generates a power measurement from a voltagemeasurement and current measurement as follows:

-   -   POST https://api.senseware.co/Convert/Node412_1/S3        {“convfxn”:“PowerFxnA”, “V_In”:“channel_1”, “I_In”:“channel_2”}        As this example illustrates, the HTTP POST method can create a        new conversion function for sensor module unit S3. In the body        of the request, the selected conversion function can represent        one of a library of conversion functions, which is identified        using an index into the library. Also specified in the body of        the request are the two sensor channel identifiers representing        the voltage input (V_In) and the current input (I_In).

Sensor application 430 can similarly use the web API to submitconfiguration settings for the second conversion function. Theconfiguration settings for the two conversion functions and the sensordata collection period are submitted via one or more method calls viathe web API and are stored in the database as settings 421.

As illustrated in FIG. 4, the stored configuration settings that specifythe new data collection period can be used by sensor data control system420 in generating a configuration setup request for delivery to gateway411 at monitored location 410. In one embodiment, the configurationsetup request is an HTTP message delivered in response to a systemstatus update message from node 412-1 (e.g., HTTP POST method) receivedby sensor data control system 420 from gateway 411 via the web API. Forexample, when the system status update is received, sensor data controlsystem 420 can compare the current configuration setting (e.g., defaultsensor data collection period) to the newly stored custom configurationsetting in the database. When the comparison indicates that the currentconfiguration does not match the newly stored custom configurationsetting, then sensor data control system 420 can initiate thetransmission of a configuration setup request having the newly storedcustom configuration setting. In one embodiment, the comparison can bebased on a computed hash value of the configuration settings that isincluded in the system status update.

The delivery of a configuration setup request by sensor data controlsystem 420 to gateway 411 is illustrated as process element “2” in FIG.4. Where the configuration setup request relates to an operation of node412-1, gateway 411 can deliver a packet containing configuration setupinformation to node 412-1 via the wireless mesh network. Thiscommunication is illustrated as process element “3” in FIG. 4.

Based on the receipt of configuration setup information via the wirelessmesh network, node 412-1 can adjust the data collection period forsensor module unit S3. This configuration change is illustrated asprocess element “4” in FIG. 4. Based on the change in configuration,node 412-1 can collect sensor readings from sensor module unit S3 at thenewly defined collection period (e.g., 60 seconds). The sensor datavalues collected at the newly defined collection period can then bedelivered to gateway 411 in data packets via the wireless mesh network.This communication is illustrated as process element “5” in FIG. 4.

In forwarding the received sensor data value to sensor data controlsystem 420, gateway 411 can prepare an HTTP POST method that submits thelatest sensor data value for recording in the database. Thiscommunication is illustrated as process element “6” in FIG. 4. Thereceived sensor data value can be stored in a database as sensor data422.

Based on the first defined conversion function stored in settings 421,sensor data control system 420 can transform sensor data 422 intoaggregation data 423. For example, sensor data control system 420 cantransform a first sensor data value based on a voltage measurement and asecond sensor data value based on a current measurement into anaggregation data value reflective of a power measurement. Based on thesecond defined conversion function stored in settings 421, sensor datacontrol system 420 can place one or more aggregation data values into adata format desired by sensor application 430. In one example, thesecond defined conversion function defines a data format for thesingular power measurement data values. In another example, the seconddefined conversion function defines a data format for multiple powermeasurement values in a report. In the illustration of FIG. 4, thecombined conversion process of the first and second defined conversionfunctions is illustrated as process element “7”. The resultingaggregation data 423 has now been prepared for the particular use bysensor application 430.

In one embodiment, sensor application 430 can retrieve sensor dataand/or aggregation data 423 using an HTTP GET method via the web API.For example, the following HTTP GET method can be used to retrievesensor data for the voltage measurement in a defined range of time(e.g., day, week, month, or other defined period of time) as follows:

-   -   GET        https://api.senseware.co/sensor/Node412-1_ID/S3_ID/Ch1_ID?from=TMk1&to=TMk2        In response to this request, sensor data control system 420 can        return a response as follows:        [{“Ch1_ID”,“data”:[[Time1,205],[Time2,203],[Time3,202],[Time4,205],[Time5,203],[Time6,20        3],[Time7,203],[Time8,202],[Time9,202],[Time10,203]}]        Here, all sensor readings between the two points in time        specified in the request are returned to sensor application 430.        The communication of sensor data 422 and/or aggregation data 423        from sensor data control system 420 to sensor application 430 is        illustrated as process element “8” in FIG. 4.

As this example process illustrates, sensor application 430 canconfigure a sensor network at a monitored location using a web API. Inthis manner, any sensor application can configure an operation of anysensor network at any monitored location to suit its particular needs.Moreover, any sensor application can configure a customized processingof sensor data collected from any sensor network at any monitoredlocation to suit its particular needs. In essence, sensor application430 can define and configure the particular sensor service it desires toreceive from sensor data control system 420. Significantly, sensorapplication 430 need not have any connection to the installation of thesensor network at the monitored location. From the perspective of sensorapplication 430, the sensor network is part of an establishedinfrastructure that is used only when sensor data is needed and in ascope that is defined by sensor application 430.

FIG. 10 illustrates a second example of a sensor application process. Inthis example, assume that sensor application 1030 requires sensor datafor a defined period of time to support an audit activity. Asillustrated, the process begins with the communication by sensorapplication 1030 of configuration settings to sensor data control system1020. This part of the process is illustrated as process element “1” inFIG. 10. In one example, sensor application 1030 can submitconfiguration settings to sensor data control system 1020 via web APIs(e.g., HTTP PUT method) that identify one or more sensors for activationfrom a deactivation state. In one scenario, the one or more sensors mayhave been deactivated after completion of a previous audit activity thatoccurred in a previous month, quarter, year, or other time period. Thereceived configuration settings can be stored in a database as settings1023.

The configuration settings that specify the activation of one or moresensors can be used by sensor data control system 1020 in generating aconfiguration setup request for delivery to gateway 1011 at monitoredlocation 1010. In one embodiment, the configuration setup request is anHTTP message delivered in response to a system status update received bysensor data control system 1020 from gateway 1011 via the web API. Thedelivery of a configuration setup request by sensor data control system1020 to gateway 1011 is illustrated as process element “2” in FIG. 10.Where the configuration setup request relates to an operation of node1012-1, gateway 1011 can deliver a packet containing configuration setupinformation to node 1012-1 via the wireless mesh network. Thiscommunication is illustrated as process element “3” in FIG. 10.

Based on the receipt of configuration setup information via the wirelessmesh network, node 1012-1 can activate one or more sensors supported bysensor module unit S3. This configuration change is illustrated asprocess element “4” in FIG. 10. Based on the change in configuration,node 1012-1 can begin to collect sensor readings for the one or morenewly activated sensors. The sensor data values collected for the one ormore newly activated sensors can then be delivered to gateway 1011 asdata packets via the wireless mesh network for subsequent delivery tosensor data control system 1020.

Additionally, node 1012-1 can provide gateway 1011 with a status packetthat includes information regarding the current configuration of node1012-1 and the supported sensor module unit S3. The communication of theinformation regarding the current configuration is illustrated asprocess element “5”. This information is then provided by gateway 1011to sensor data control system 1020 as part of a status update, which isillustrated as process element “6”. The information regarding thecurrent configuration can then be stored in a database as system status1024.

The stored system status 1024 would then be available for presentationto sensor application 1030. In one embodiment, sensor application 1030can retrieve system status 1024 using an HTTP GET method via the webAPI. The communication of system status 1024 from sensor data controlsystem 1020 to sensor application 1030 in response to the HTTP GETmethod request is illustrated as process element “7” in FIG. 10. Ingeneral, the provision of system status information to sensorapplication 1030 enables sensor application 1030 to confirm that thesensor network has been configured as specified.

The confirmation of system status in the context of configurationrequests can play a key role in the utility of a sensor service. Forexample, a confirmation of sensor activation would enable sensorapplication 1030 to determine that needed sensor service functionalityin a mission critical application (e.g., auditing) is now online. Inanother example, a confirmation of sensor deactivation would enablesensor application 1030 to determine that sensor service functionalityhas been disabled and that billing charges will not continue to accrue.

FIG. 11 illustrates a third example of a sensor application process. Inthis example, assume that sensor application 1130 receives sensor dataand/or aggregation data from sensor data control system 1120 via the webAPI. This acquisition of sensor data and/or aggregation data can enablesensor application 1130 to perform a demand analysis on the sensor dataand/or aggregation data.

In a simple example, the demand analysis can be configured to comparesensor data and/or aggregation data to one or more threshold values(e.g., temperature reading from sensor X is greater than a thresholdtemperature value). The result of this comparison enables determinationof whether a response action should be taken. In a more complex example,the demand analysis can be based on a defined demand estimation functionsuch as f×n(sensor1, sensor2, . . . sensorN). In yet another example,the demand analysis can represent a combinatorial analysis of multipleinput values. Here, a conditional analysis of multiple independentdemand components (e.g., (sensor1>X1 AND sensor2>X2) OR sensor3<X3)) canbe performed to estimate a demand. As would be appreciated, a demandanalysis based on a plurality of sources of sensor data and/oraggregation data can be defined to infer a particular change in demandat a monitored location.

The demand analysis performed by sensor application 1130 can beconfigured to produce a response trigger. In one embodiment, thisresponse trigger can be used to effect a response action using one ormore control nodes 1112-n installed at monitored location 1110. In oneembodiment, control nodes 1112-n can be connected to gateway 1111through wireless connections. In another embodiment, control nodes1112-n can be connected to gateway 1111 through wired connections.

Each control node 1112-n can support one or more actuators (A) that canbe used to effect a response action at monitored location 1110. In oneexample, control nodes 1112-n can be similar to the example nodesdescribed with reference to FIG. 5. In this framework, control nodes1112-n can also include a universal interface that enables attachment ofone or more actuator module units. In one embodiment, the actuatorscould be integrated with the control node. In another embodiment, acontrol node can represent a node to which a sensor module unit and/oran actuator module unit is attached.

Actuator module units can be configured to effect various types ofresponse actions at monitored location 1110. As such, the plug-and-playnature of actuator module units would provide significant flexibility inconfiguring and/or re-configuring the response actions that are desiredto be effected at monitored location 1110. The particular types ofresponse actions that can be effected would be implementation dependent.To illustrate a range of the types of response actions that can beeffected by the actuators, consider the following demand/response systemexamples.

In one example, the demand/response model can be designed to effect afeedback loop to control resource consumption at monitored location1110. In this scenario, the collection of sensor data and/or aggregationdata can be designed to enable an estimate of demand for a particularresource (e.g., water, electricity or gas consumption) at monitoredlocation 1110. Based on the demand analysis, sensor application 1130 canthen generate response message(s) that are configured to adjust futureconsumption of the particular resource at monitored location 1110. In asimple example, the response message(s) can be designed to instruct anactuator to initiate the display of a visual alert to personnel atmonitored location 1110 that the consumption of the particular resourceis exceeding a threshold. Here, the visual alert can be provided by theactuator itself, or by another device coupled to the actuator. Inanother example, the response message(s) can be designed to instruct anactuator to transmit a control signal to a device to alter consumptionof the particular resource. In one scenario, the actuator control signalcan shut down or otherwise limit the operation (e.g., reduce lightoutput) of a device that consumes the particular resource. In yetanother example, the response message(s) can be designed to instruct anactuator to transmit a control signal to a device that governs thesupply of the particular resource to monitored location 1110. In onescenario, the control signal can lower the maximum rate at which theparticular resource can be supplied to monitored location 1110.

In another example, the demand/response model can be designed tomaintain a desired status at monitored location 1110. In this scenario,the sensor data and/or aggregation data can be designed to enabledetermination of the current state of a measureable quantity atmonitored location 1110. In one example, the measurable quantity canrepresent a temperature of a room or area, a supply level of a resource,a fullness of a storage or inventory area, an efficiency of operation ofone or more components, a level of activity or traffic, or any otherquantity having a level or target that is desired. In this scenario, thesensor data and/or aggregation data can be used to determine the currentstate of the measurable quantity. If the demand analysis indicates thatthe current state of the measurable quantity has hit a level of variancerelative to a target level, wherein the level of variance is beyond athreshold variance, then sensor application 1130 can generate one ormore response messages that can instruct one or more actuators atmonitored location 1110 to transmit a control signal that is operativeto reduce the variance in the measurable quantity.

For example, there may exist an area at monitored location 1110 thatdesires the temperature and/or humidity to be maintained at a certainlevel (e.g., refrigerated area, server room, surgical room, or othertemperature and/or humidity sensitive environment). When the analysis ofsensor data and/or aggregation data indicate that the currenttemperature and/or humidity has deviated too much from a target level,then one or more response messages can be produced to instruct anactuator to generate a control signal to adjust the operation of an HVACsystem that governs the particular area of monitored location 1110 oradjust a level of operation of one or more components that impacts thetemperature and/or humidity at that particular area of monitoredlocation 1110. For example, a control signal can be used to modify theoperation of a heat-generating component.

In another example, sensor data and/or aggregation data can be used todetect sub-optimal operation of one or more components at monitoredlocation 1110. In one scenario, temperature sensor readings can be usedto measure how well a current chiller (e.g., machine that cools air, asubstance or equipment) is working and to generate a control signal thatcan be used to signal the need for repair or for a new chiller to beobtained. For example, the control signal can be used to provide contactinformation for a repair technician or sales representative. In anotherscenario, sensor data and/or aggregation data that are indicative ofpower consumption relative to efficiency of operation can be used tosignal the need for repair or for a new unit to be obtained. In effect,the analysis of sensor data and/or aggregation data can be used toproduce sales opportunities at monitored location 1110.

More generally, sensor data and/or aggregation data can be used todetect malfunctions in equipment where a deviation from an expectedlevel of operation is detected through analysis. For example, a sumppump sensor can be used to detect when a sump pump is not working, orworking inefficiently. One or more response messages can then beproduced to instruct an actuator to generate a control signal to alertrelevant personnel at monitored location 1110. In another example,sensor data and/or aggregation data can be used to detect water leaks(e.g., water sensor) and for generating one or more response messagesthat can be used by an actuator to generate a control signal to alertrelevant personnel at monitored location 1110 in a timely manner.

In another example, the demand/response model can be designed todiscover and release unused resources at monitored location 1110. Inthis scenario, sensor data and/or aggregation data can be designed toeffect a determination of the current usage of resources at monitoredlocation 1110. In this context, the resources can represent temporary orshared offices, conference rooms, common areas, storage facilities, orother physical resources at monitored location 1110 that can bere-purposed or otherwise leveraged in a new capacity. In one example,sensor data and/or aggregation data can be used to determine the currentusage of a defined physical space by individuals, inanimate objects, orother items that have usage characteristics. If the demand analysisindicates that the defined physical space is unused or used at a levelbelow a threshold amount, then sensor application 1130 can generate oneor more response messages that can instruct actuators at monitoredlocation 1110 to transmit a control signal that is used to signal theavailability of at least part of the defined physical space. Oneapplication of such a demand/response model is to enable workplacereservation optimization such that reserved resources (e.g., conferencerooms) are released when sensor data and/or aggregation data (e.g.,light and sound) indicate that the reserved resource is not being used.When sensor data and/or aggregation data indicate that the reservedresource is not being used, then one or more response messages can beused (e.g., message to a resource manager, receptionist, or other partyresponsible for overseeing use of the reserved resource) to release thereservation or otherwise indicate the current availability of apreviously-reserved resource.

In a related application, the demand/response model can be used todetermine and signal when resources can be used. For example, sensordata and/or aggregation data can be used to detect harmful conditionsthat preclude the occurrence of organized activities. For example, wetbulb globe temperature (WBGT) sensor readings, which represent acomposite temperature used to estimate the effect of temperature,humidity, wind speed (wind chill), and visible and infrared radiation(usually sunlight) on humans, can be used to detect whether organizedoutdoor activities should be held in a school, a military base, or otherorganization hosting an outdoor event. In a simple example, sensorapplication 1130 can generate one or more response messages that caninstruct actuators at monitored location 1110 to transmit a firstcontrol signal that is used to indicate that an organized activity canbe held (e.g., green light), a second control signal that is used toindicate than an organized activity cannot be held (e.g., red light), oranother control signal that is used to indicate one or more restrictionsfor an organized activity (e.g., warning lights and instructions).

As has been described, the demand/response model can represent ascenario where the demand analysis performed on sensor data and/oraggregation data is used to initiate one or more response actions by oneor more actuators at monitored location 1110. The exact form of theresponse action and the control signal mechanism used by the actuatorthat effects the response action can vary based on the sensorapplication. As noted with reference to FIG. 3, sensor applicationsdirected to different segments of the marketplace can desire differenttypes of control actions.

In the present disclosure, it is recognized that the response messagesproduced by sensor application 1130 based on a demand/response model canrepresent a request for a configuration change of an actuator unit atmonitored location 1110. In submitting configuration settings to sensordata control system 1120, sensor application 1130 can use an HTTP PUTmethod to update a configuration setting that controls an operation ofan actuator unit. This part of the process is illustrated as processelement “1” in FIG. 11. The submitted configuration settings can bestored in a database as settings 1123, and can be used as the basis foradjusting the configuration of an actuator unit at monitored location1110.

As illustrated in FIG. 11, the stored configuration setting thatspecifies the operation of an actuator unit can be used by sensor datacontrol system 1120 in generating a response message for delivery togateway 1111 at monitored location 1110. The delivery of a responsemessage by sensor data control system 1120 to gateway 1111 isillustrated as process element “2” in FIG. 11. Where the responsemessage relates to an operation of actuator unit A1 supported by node1112-1, gateway 1111 can deliver a packet containing actuator controlinformation to node 1112-1 via the wireless mesh network. Thiscommunication is illustrated as process element “3” in FIG. 11.

Based on the receipt of actuator control information via the wirelessmesh network, node 1112-1 can deliver the actuator control informationto actuator unit A1 to effect a control action desired by sensorapplication 1130. This control action is illustrated as process element“4” in FIG. 11.

As has been described, the sensors as a service model promotes the openusage of sensors and the data collected by them to any party having aninterest in at least part of a monitored location. Discrete sensorapplications can be developed to leverage the sensor service forparticular industry or application segments.

Another embodiment of the present disclosure can provide a machineand/or computer readable storage and/or medium, having stored thereon, amachine code and/or a computer program having at least one code sectionexecutable by a machine and/or a computer, thereby causing the machineand/or computer to perform the steps as described herein.

Those of skill in the relevant art would appreciate that the variousillustrative blocks, modules, elements, components, and methodsdescribed herein may be implemented as electronic hardware, computersoftware, or combinations of both. To illustrate this interchangeabilityof hardware and software, various illustrative blocks, modules,elements, components, methods, and algorithms have been described abovegenerally in terms of their functionality. Whether such functionality isimplemented as hardware or software depends upon the particularapplication and design constraints imposed on the overall system. Thoseof skill in the relevant art can implement the described functionalityin varying ways for each particular application. Various components andblocks may be arranged differently (e.g., arranged in a different order,or partitioned in a different way) all without departing from the scopeof the subject technology.

These and other aspects of the present disclosure will become apparentto those skilled in the relevant art by a review of the precedingdetailed disclosure. Although a number of salient features of thepresent disclosure have been described above, the principles in thepresent disclosure are capable of other embodiments and of beingpracticed and carried out in various ways that would be apparent to oneof skill in the relevant art after reading the present disclosure,therefore the above disclosure should not be considered to be exclusiveof these other embodiments. Also, it is to be understood that thephraseology and terminology employed herein are for the purposes ofdescription and should not be regarded as limiting.

What is claimed is:
 1. A method, comprising: transmitting, to a sensordata control system, a first hypertext transfer protocol message via theInternet, the first hypertext transfer protocol message requesting achange in Modbus configuration information for a wireless node in awireless sensor network at a monitored location, the Modbusconfiguration information used to configure the wireless node totransmit periodic Modbus interface command requests to a Modbus deviceconnected to the wireless node via a wired interface, each of theperiodic Modbus interface command requests designed to retrieve sensordata based on measurements by one or more of a plurality of sensorssupported by the Modbus device, the first hypertext transfer protocolmessage including a wireless node identifier, and one or moreconfiguration data values reflective of the change; transmitting, to thesensor data control system, a second hypertext transfer protocol messagevia the Internet, the second hypertext transfer protocol messagerequesting a series of sensor data based on measurements by a first ofthe plurality of sensors, the series of sensor data retrieved from theModbus device in response to a transmission of a series of Modbusinterface command requests by the wireless node to the Modbus device,the second hypertext transfer protocol message including the wirelessnode identifier; and receiving, from the sensor data control system inresponse to the second hypertext transfer protocol message, the seriesof sensor data based on the measurements by the first of the pluralityof sensors.
 2. The method of claim 1, further comprising transmitting,to the sensor data control system, a third hypertext transfer protocolmessage via the Internet, the third hypertext transfer protocol messagerequesting an activation of a sensor in the wireless node from adeactivated state.
 3. The method of claim 1, further comprisingtransmitting, to the sensor data control system, a third hypertexttransfer protocol message via the Internet, the third hypertext transferprotocol message requesting a change in configuration in a measurementresolution of a sensor.
 4. The method of claim 1, further comprisingtransmitting, to the sensor data control system, a third hypertexttransfer protocol message via the Internet, the third hypertext transferprotocol message requesting a reset of the wireless node.
 5. The methodof claim 1, wherein the one or more configuration data values includesan identification of a device address for the Modbus interface commandrequests.
 6. The method of claim 1, wherein the one or moreconfiguration data values includes an identification of a registeraddress for the Modbus interface command requests.
 7. The method ofclaim 1, further comprising: analyzing the received series of sensordata to estimate a demand for a resource at the monitored location; andtransmitting, to the sensor data control system, a third hypertexttransfer protocol message via the Internet, the third hypertext transferprotocol message requesting a change in configuration of an actuatorunit at the monitored location to effect a response action identifiedbased on the analysis.
 8. A method, comprising: receiving, from a clientdevice, a first hypertext transfer protocol message via the Internet,the first hypertext transfer protocol message requesting a change inModbus configuration information for a wireless node in a wirelesssensor network at a monitored location, the Modbus configurationinformation used to configure the wireless node to transmit periodicModbus interface command requests to a Modbus device connected to thewireless node via a wired interface, each of the periodic Modbusinterface command requests designed to retrieve sensor data based onmeasurements by one or more of a plurality of sensors supported by theModbus device, the first hypertext transfer protocol change messageincluding a wireless node identifier, and configuration informationreflective of the change; transmitting, to a gateway device at themonitored location, a second hypertext transfer protocol message via theInternet that includes an instruction to effect the change in theconfiguration of the wireless node to transmit the periodic Modbusinterface command requests to the Modbus device, the second hypertexttransfer protocol message including one or more configuration datavalues based on the configuration information; receiving, from thegateway device, a third hypertext transfer protocol message thatincludes first information about an updated configuration of thewireless node; updating, based on the received first information, astored current status of the updated configuration of the wireless node;and transmitting, to the client device, a fourth hypertext transferprotocol message that includes second information about the updatedconfiguration of the wireless node, the second information enabling theclient device to confirm that the current status of the updatedconfiguration of the wireless node reflects the in Modbus configurationinformation requested in the first hypertext transfer protocol message.9. The method of claim 8, further comprising transmitting, to thegateway device, a fifth hypertext transfer protocol message that isconfigured to activate a sensor in the wireless node from a deactivatedstate.
 10. The method of claim 8, further comprising transmitting, tothe gateway device, a fifth hypertext transfer protocol message that isconfigured to change a measurement resolution of a sensor.
 11. Themethod of claim 8, further comprising transmitting, to the gatewaydevice, a fifth hypertext transfer protocol message that is configuredto reset the wireless node.
 12. The method of claim 8, wherein the oneor more configuration data values includes a device address for theModbus interface command requests.
 13. The method of claim 8, whereinthe one or more configuration data values includes a register addressfor the Modbus interface command requests.